تحديد معدل الطلبات في بايثون: خوارزمية دلو الرموز مقابل النافذة المنزلقة - دليل شامل

في عالمنا المترابط اليوم، تُعد واجهات برمجة التطبيقات (APIs) القوية حاسمة لنجاح التطبيقات. ومع ذلك، يمكن أن يؤدي الوصول غير المنضبط إلى واجهات برمجة التطبيقات إلى زيادة تحميل الخوادم، وتدهور الخدمة، وحتى هجمات حجب الخدمة (DoS). يعد تحديد معدل الطلبات تقنية حيوية لحماية واجهات برمجة التطبيقات الخاصة بك عن طريق تقييد عدد الطلبات التي يمكن للمستخدم أو الخدمة إجراؤها ضمن إطار زمني محدد. تتعمق هذه المقالة في اثنتين من خوارزميات تحديد معدل الطلبات الشائعة في بايثون: دلو الرموز (Token Bucket) والنافذة المنزلقة (Sliding Window)، مقدمة مقارنة شاملة وأمثلة عملية للتطبيق.

لماذا يعد تحديد معدل الطلبات مهمًا

يقدم تحديد معدل الطلبات العديد من الفوائد، بما في ذلك:

• منع سوء الاستخدام: يحد من قيام المستخدمين الضارين أو الروبوتات بإغراق خوادمك بالطلبات المفرطة.
• ضمان الاستخدام العادل: يوزع الموارد بالتساوي بين المستخدمين، مما يمنع مستخدمًا واحدًا من احتكار النظام.
• حماية البنية التحتية: يحمي خوادمك وقواعد بياناتك من التحميل الزائد والتعطل.
• التحكم في التكاليف: يمنع الارتفاعات غير المتوقعة في استهلاك الموارد، مما يؤدي إلى توفير التكاليف.
• تحسين الأداء: يحافظ على أداء مستقر عن طريق منع استنزاف الموارد وضمان أوقات استجابة ثابتة.

فهم خوارزميات تحديد معدل الطلبات

توجد العديد من خوارزميات تحديد معدل الطلبات، ولكل منها نقاط قوتها وضعفها. سنركز على اثنتين من الخوارزميات الأكثر استخدامًا: دلو الرموز (Token Bucket) والنافذة المنزلقة (Sliding Window).

1. خوارزمية دلو الرموز

تُعد خوارزمية دلو الرموز تقنية بسيطة وواسعة الاستخدام لتحديد معدل الطلبات. تعمل عن طريق الاحتفاظ بـ "دلو" يحتوي على رموز. يمثل كل رمز إذنًا لإجراء طلب واحد. للدلو سعة قصوى، وتتم إضافة الرموز إلى الدلو بمعدل ثابت.

عند وصول طلب، يتحقق محدد معدل الطلبات مما إذا كانت هناك رموز كافية في الدلو. إذا كانت كذلك، يُسمح بالطلب، ويتم إزالة العدد المقابل من الرموز من الدلو. إذا كان الدلو فارغًا، يتم رفض الطلب أو تأخيره حتى تصبح هناك رموز كافية متاحة.

تطبيق خوارزمية دلو الرموز في بايثون

إليك تطبيق بايثون أساسي لخوارزمية دلو الرموز باستخدام وحدة threading لإدارة التزامن:

import time
import threading

class TokenBucket:
    def __init__(self, capacity, fill_rate):
        self.capacity = float(capacity)
        self._tokens = float(capacity)
        self.fill_rate = float(fill_rate)
        self.last_refill = time.monotonic()
        self.lock = threading.Lock()

    def _refill(self):
        now = time.monotonic()
        delta = now - self.last_refill
        tokens_to_add = delta * self.fill_rate
        self._tokens = min(self.capacity, self._tokens + tokens_to_add)
        self.last_refill = now

    def consume(self, tokens):
        with self.lock:
            self._refill()
            if self._tokens >= tokens:
                self._tokens -= tokens
                return True
            return False

# Example Usage
bucket = TokenBucket(capacity=10, fill_rate=2)  # 10 tokens, refill at 2 tokens per second

for i in range(15):
    if bucket.consume(1):
        print(f"Request {i+1}: Allowed")
    else:
        print(f"Request {i+1}: Rate Limited")
    time.sleep(0.2)

شرح:

• TokenBucket(capacity, fill_rate): تهيئ الدلو بسعة قصوى ومعدل تعبئة (رموز في الثانية).
• _refill(): تعيد تعبئة الدلو بالرموز بناءً على الوقت المنقضي منذ آخر تعبئة.
• consume(tokens): تحاول استهلاك العدد المحدد من الرموز. تُرجع True إذا نجحت (تم السماح بالطلب)، False بخلاف ذلك (تم تقييد الطلب).
• قفل التزامن (Threading Lock): تستخدم قفل تزامن (self.lock) لضمان أمان الخيوط (thread safety) في البيئات المتزامنة.

مزايا دلو الرموز

• سهل التنفيذ: مباشر نسبيًا من حيث الفهم والتنفيذ.
• معالجة الاندفاعات: يمكنه التعامل مع الاندفاعات العرضية في حركة المرور طالما أن الدلو يحتوي على رموز كافية.
• قابل للتكوين: يمكن تعديل السعة ومعدل التعبئة بسهولة لتلبية متطلبات محددة.

عيوب دلو الرموز

• غير دقيق تمامًا: قد يسمح بعدد طلبات أكثر قليلاً من المعدل المكون بسبب آلية التعبئة.
• ضبط المعلمات: يتطلب اختيارًا دقيقًا للسعة ومعدل التعبئة لتحقيق سلوك تحديد معدل الطلبات المطلوب.

2. خوارزمية النافذة المنزلقة

تُعد خوارزمية النافذة المنزلقة تقنية أكثر دقة لتحديد معدل الطلبات تقسم الوقت إلى نوافذ ذات حجم ثابت. تتتبع عدد الطلبات التي تم إجراؤها داخل كل نافذة. عند وصول طلب جديد، تتحقق الخوارزمية مما إذا كان عدد الطلبات داخل النافذة الحالية يتجاوز الحد. إذا كان كذلك، يتم رفض الطلب أو تأخيره.

يأتي جانب "الانزلاق" من حقيقة أن النافذة تتحرك إلى الأمام في الوقت مع وصول الطلبات الجديدة. عندما تنتهي النافذة الحالية، تبدأ نافذة جديدة، ويتم إعادة تعيين العداد. هناك نوعان رئيسيان من خوارزمية النافذة المنزلقة: السجل المنزلق (Sliding Log) وعداد النافذة الثابتة (Fixed Window Counter).

2.1. السجل المنزلق

تحتفظ خوارزمية السجل المنزلق بسجل بتاريخ زمني لكل طلب يتم إجراؤه ضمن نافذة زمنية معينة. عندما يأتي طلب جديد، فإنها تجمع كل الطلبات في السجل التي تقع ضمن النافذة وتقارن ذلك بحد معدل الطلبات. هذه الخوارزمية دقيقة، ولكنها قد تكون مكلفة من حيث الذاكرة وقوة المعالجة.

2.2. عداد النافذة الثابتة

تقسم خوارزمية عداد النافذة الثابتة الوقت إلى نوافذ ثابتة وتحتفظ بعداد لكل نافذة. عند وصول طلب جديد، تزيد الخوارزمية العداد للنافذة الحالية. إذا تجاوز العداد الحد، يتم رفض الطلب. هذه الخوارزمية أبسط من السجل المنزلق، ولكنها قد تسمح باندفاع من الطلبات عند حدود نافذتين.

تطبيق خوارزمية النافذة المنزلقة في بايثون (عداد النافذة الثابتة)

إليك تطبيق بايثون لخوارزمية النافذة المنزلقة باستخدام نهج عداد النافذة الثابتة:

import time
import threading

class SlidingWindowCounter:
    def __init__(self, window_size, max_requests):
        self.window_size = window_size  # seconds
        self.max_requests = max_requests
        self.request_counts = {}
        self.lock = threading.Lock()

    def is_allowed(self, client_id):
        with self.lock:
            current_time = int(time.time())
            window_start = current_time - self.window_size

            # Clean up old requests
            self.request_counts = {ts: count for ts, count in self.request_counts.items() if ts > window_start}

            total_requests = sum(self.request_counts.values())

            if total_requests < self.max_requests:
                self.request_counts[current_time] = self.request_counts.get(current_time, 0) + 1
                return True
            else:
                return False


# Example Usage
window_size = 60  # 60 seconds
max_requests = 10  # 10 requests per minute
rate_limiter = SlidingWindowCounter(window_size, max_requests)

client_id = "user123"

for i in range(15):
    if rate_limiter.is_allowed(client_id):
        print(f"Request {i+1}: Allowed")
    else:
        print(f"Request {i+1}: Rate Limited")
    time.sleep(5)

شرح:

• SlidingWindowCounter(window_size, max_requests): تهيئ حجم النافذة (بالثواني) والحد الأقصى لعدد الطلبات المسموح بها ضمن النافذة.
• is_allowed(client_id): تتحقق مما إذا كان العميل مسموحًا له بإجراء طلب. تقوم بتنظيف الطلبات القديمة خارج النافذة، وتلخص الطلبات المتبقية، وتزيد العداد للنافذة الحالية إذا لم يتم تجاوز الحد.
• self.request_counts: قاموس يخزن طوابع زمنية للطلبات وعددها، مما يسمح بتجميع وتنظيف الطلبات القديمة.
• قفل التزامن (Threading Lock): تستخدم قفل تزامن (self.lock) لضمان أمان الخيوط (thread safety) في البيئات المتزامنة.

مزايا النافذة المنزلقة

• أكثر دقة: توفر تحديد معدل طلبات أكثر دقة من دلو الرموز، خاصةً تطبيق السجل المنزلق.
• تمنع الاندفاعات عند الحدود: تقلل من احتمالية حدوث اندفاعات عند حدود نافذتين زمنيتين (بشكل أكثر فعالية مع السجل المنزلق).

عيوب النافذة المنزلقة

• أكثر تعقيدًا: أكثر تعقيدًا في التنفيذ والفهم مقارنة بدلو الرموز.
• عبء إضافي أعلى: قد يكون لها عبء إضافي أعلى، خاصةً تطبيق السجل المنزلق، بسبب الحاجة إلى تخزين ومعالجة سجلات الطلبات.

دلو الرموز مقابل النافذة المنزلقة: مقارنة تفصيلية

إليك جدول يلخص الفروق الرئيسية بين خوارزميتي دلو الرموز والنافذة المنزلقة:

الميزة	دلو الرموز	النافذة المنزلقة
التعقيد	أبسط	أكثر تعقيدًا
الدقة	أقل دقة	أكثر دقة
معالجة الاندفاعات	جيد	جيد (خاصة السجل المنزلق)
العبء الإضافي	أقل	أعلى (خاصة السجل المنزلق)
جهد التنفيذ	أسهل	أصعب

اختيار الخوارزمية الصحيحة

يعتمد الاختيار بين دلو الرموز والنافذة المنزلقة على متطلباتك وأولوياتك المحددة. ضع في اعتبارك العوامل التالية:

• الدقة: إذا كنت بحاجة إلى تحديد معدل طلبات عالي الدقة، فإن خوارزمية النافذة المنزلقة هي المفضلة بشكل عام.
• التعقيد: إذا كانت البساطة أولوية، فإن خوارزمية دلو الرموز خيار جيد.
• الأداء: إذا كان الأداء حاسمًا، ففكر بعناية في العبء الإضافي لخوارزمية النافذة المنزلقة، خاصة تطبيق السجل المنزلق.
• معالجة الاندفاعات: يمكن لكلتا الخوارزميتين التعامل مع اندفاعات حركة المرور، ولكن النافذة المنزلقة (السجل المنزلق) توفر تحديد معدل طلبات أكثر اتساقًا في ظل الظروف المتقطعة.
• قابلية التوسع: للأنظمة عالية التوسع، فكر في استخدام تقنيات تحديد معدل الطلبات الموزعة (التي ستُناقش أدناه).

في العديد من الحالات، توفر خوارزمية دلو الرموز مستوى كافيًا من تحديد معدل الطلبات بتكلفة تنفيذ منخفضة نسبيًا. ومع ذلك، بالنسبة للتطبيقات التي تتطلب تحديد معدل طلبات أكثر دقة ويمكنها تحمل التعقيد المتزايد، فإن خوارزمية النافذة المنزلقة خيار أفضل.

تحديد معدل الطلبات الموزع

في الأنظمة الموزعة، حيث تتعامل خوادم متعددة مع الطلبات، غالبًا ما تكون هناك حاجة إلى آلية مركزية لتحديد معدل الطلبات لضمان تحديد معدل طلبات متسق عبر جميع الخوادم. يمكن استخدام عدة أساليب لتحديد معدل الطلبات الموزع:

• مخزن بيانات مركزي: استخدم مخزن بيانات مركزيًا، مثل Redis أو Memcached، لتخزين حالة تحديد معدل الطلبات (مثل عدد الرموز أو سجلات الطلبات). تصل جميع الخوادم إلى مخزن البيانات المشترك وتحدثه لفرض قيود المعدل.
• تحديد معدل الطلبات بواسطة موازن التحميل: قم بتكوين موازن التحميل الخاص بك لأداء تحديد معدل الطلبات بناءً على عنوان IP أو معرف المستخدم أو معايير أخرى. يمكن لهذا النهج تخفيف عبء تحديد معدل الطلبات عن خوادم التطبيقات الخاصة بك.
• خدمة مخصصة لتحديد معدل الطلبات: أنشئ خدمة مخصصة لتحديد معدل الطلبات تتولى جميع طلبات تحديد المعدل. يمكن لهذه الخدمة أن تتوسع بشكل مستقل ويتم تحسينها للأداء.
• تحديد معدل الطلبات من جانب العميل: على الرغم من أنها ليست دفاعًا أساسيًا، قم بإبلاغ العملاء بحدود معدل الطلبات الخاصة بهم عبر رؤوس HTTP (مثل X-RateLimit-Limit، X-RateLimit-Remaining، X-RateLimit-Reset). يمكن أن يشجع هذا العملاء على تقييد أنفسهم وتقليل الطلبات غير الضرورية.

إليك مثال على استخدام Redis مع خوارزمية دلو الرموز لتحديد معدل الطلبات الموزع:

import redis
import time

class RedisTokenBucket:
    def __init__(self, redis_client, bucket_key, capacity, fill_rate):
        self.redis_client = redis_client
        self.bucket_key = bucket_key
        self.capacity = capacity
        self.fill_rate = fill_rate

    def consume(self, tokens):
        now = time.time()
        capacity = self.capacity
        fill_rate = self.fill_rate

        # Lua script to atomically update the token bucket in Redis
        script = '''
        local bucket_key = KEYS[1]
        local capacity = tonumber(ARGV[1])
        local fill_rate = tonumber(ARGV[2])
        local tokens_to_consume = tonumber(ARGV[3])
        local now = tonumber(ARGV[4])

        local last_refill = redis.call('get', bucket_key .. ':last_refill')
        if not last_refill then
            last_refill = now
            redis.call('set', bucket_key .. ':last_refill', now)
        else
            last_refill = tonumber(last_refill)
        end

        local tokens = redis.call('get', bucket_key .. ':tokens')
        if not tokens then
            tokens = capacity
            redis.call('set', bucket_key .. ':tokens', capacity)
        else
            tokens = tonumber(tokens)
        end

        -- Refill the bucket
        local time_since_last_refill = now - last_refill
        local tokens_to_add = time_since_last_refill * fill_rate
        tokens = math.min(capacity, tokens + tokens_to_add)

        -- Consume tokens
        if tokens >= tokens_to_consume then
            tokens = tokens - tokens_to_consume
            redis.call('set', bucket_key .. ':tokens', tokens)
            redis.call('set', bucket_key .. ':last_refill', now)
            return 1  -- Success
        else
            return 0  -- Rate limited
        end
        '''

        # Execute the Lua script
        consume_script = self.redis_client.register_script(script)
        result = consume_script(keys=[self.bucket_key], args=[capacity, fill_rate, tokens, now])
        return result == 1


# Example Usage
redis_client = redis.StrictRedis(host='localhost', port=6379, db=0)
bucket = RedisTokenBucket(redis_client, bucket_key='my_api:user123', capacity=10, fill_rate=2)

for i in range(15):
    if bucket.consume(1):
        print(f"Request {i+1}: Allowed")
    else:
        print(f"Request {i+1}: Rate Limited")
    time.sleep(0.2)

اعتبارات هامة للأنظمة الموزعة:

• الذرية (Atomicity): تأكد من أن عمليات استهلاك الرموز أو عد الطلبات ذرية لمنع حالات السباق (race conditions). توفر نصوص Redis Lua البرمجية عمليات ذرية.
• زمن الانتقال (Latency): قلل زمن انتقال الشبكة عند الوصول إلى مخزن البيانات المركزي.
• قابلية التوسع: اختر مخزن بيانات يمكنه التوسع للتعامل مع الحمل المتوقع.
• اتساق البيانات: عالج مشكلات اتساق البيانات المحتملة في البيئات الموزعة.

أفضل الممارسات لتحديد معدل الطلبات

إليك بعض أفضل الممارسات التي يجب اتباعها عند تطبيق تحديد معدل الطلبات:

• تحديد متطلبات تحديد معدل الطلبات: حدد حدود المعدل المناسبة لنقاط نهاية API ومجموعات المستخدمين المختلفة بناءً على أنماط استخدامهم واستهلاك الموارد. فكر في تقديم وصول متعدد المستويات بناءً على مستوى الاشتراك.
• استخدام رموز حالة HTTP ذات معنى: أرجع رموز حالة HTTP المناسبة للإشارة إلى تحديد معدل الطلبات، مثل 429 Too Many Requests.
• تضمين رؤوس حدود المعدل: قم بتضمين رؤوس حدود المعدل في استجابات API الخاصة بك لإبلاغ العملاء بحالة حدود المعدل الحالية (على سبيل المثال، X-RateLimit-Limit، X-RateLimit-Remaining، X-RateLimit-Reset).
• توفير رسائل خطأ واضحة: قدم رسائل خطأ مفيدة للعملاء عندما يتم تقييد معدل طلباتهم، موضحًا السبب ومقترحًا كيفية حل المشكلة. قدم معلومات الاتصال للدعم.
• تطبيق التدهور التدريجي: عند فرض تحديد معدل الطلبات، فكر في توفير خدمة متدهورة بدلاً من حظر الطلبات بالكامل. على سبيل المثال، قدم بيانات مخبأة أو وظائف مخفضة.
• مراقبة وتحليل تحديد معدل الطلبات: راقب نظام تحديد معدل الطلبات الخاص بك لتحديد المشكلات المحتملة وتحسين أدائه. حلل أنماط الاستخدام لتعديل حدود المعدل حسب الحاجة.
• تأمين تحديد معدل الطلبات الخاص بك: امنع المستخدمين من تجاوز حدود المعدل عن طريق التحقق من صحة الطلبات وتطبيق تدابير الأمان المناسبة.
• توثيق حدود المعدل: وثّق بوضوح سياسات تحديد معدل الطلبات في وثائق API الخاصة بك. قدم أمثلة تعليمات برمجية توضح للعملاء كيفية التعامل مع حدود المعدل.
• اختبار تطبيقك: اختبر تطبيق تحديد معدل الطلبات الخاص بك بدقة تحت ظروف تحميل مختلفة لضمان عمله بشكل صحيح.
• مراعاة الفروق الإقليمية: عند النشر عالميًا، ضع في اعتبارك الفروق الإقليمية في زمن انتقال الشبكة وسلوك المستخدم. قد تحتاج إلى تعديل حدود المعدل بناءً على المنطقة. على سبيل المثال، قد يتطلب سوق يعتمد على الهاتف المحمول أولاً مثل الهند حدود معدل مختلفة مقارنة بمنطقة ذات نطاق ترددي عالٍ مثل كوريا الجنوبية.

أمثلة من العالم الحقيقي

• تويتر: يستخدم تويتر تحديد معدل الطلبات بشكل واسع لحماية واجهة برمجة التطبيقات الخاصة به من سوء الاستخدام وضمان الاستخدام العادل. يقدمون وثائق مفصلة حول حدود المعدل الخاصة بهم ويستخدمون رؤوس HTTP لإبلاغ المطورين بحالة حدود المعدل لديهم.
• جيت هاب: تستخدم جيت هاب أيضًا تحديد معدل الطلبات لمنع سوء الاستخدام والحفاظ على استقرار واجهة برمجة التطبيقات الخاصة بها. يستخدمون مزيجًا من حدود المعدل القائمة على عنوان IP والمستخدم.
• سترايب: تستخدم سترايب تحديد معدل الطلبات لحماية واجهة برمجة التطبيقات لمعالجة المدفوعات من النشاط الاحتيالي وضمان خدمة موثوقة لعملائها.
• منصات التجارة الإلكترونية: تستخدم العديد من منصات التجارة الإلكترونية تحديد معدل الطلبات للحماية من هجمات الروبوتات التي تحاول استخراج معلومات المنتج أو تنفيذ هجمات حجب الخدمة خلال المبيعات السريعة.
• المؤسسات المالية: تطبق المؤسسات المالية تحديد معدل الطلبات على واجهات برمجة التطبيقات الخاصة بها لمنع الوصول غير المصرح به إلى البيانات المالية الحساسة وضمان الامتثال للمتطلبات التنظيمية.

الخاتمة

تحديد معدل الطلبات هو تقنية أساسية لحماية واجهات برمجة التطبيقات الخاصة بك وضمان استقرار وموثوقية تطبيقاتك. تُعد خوارزميتا دلو الرموز والنافذة المنزلقة خيارين شائعين، ولكل منهما نقاط قوته وضعفه. من خلال فهم هذه الخوارزميات واتباع أفضل الممارسات، يمكنك تطبيق تحديد معدل الطلبات بفعالية في تطبيقات بايثون الخاصة بك وبناء أنظمة أكثر مرونة وأمانًا. تذكر أن تأخذ في الاعتبار متطلباتك المحددة، واختيار الخوارزمية المناسبة بعناية، ومراقبة تطبيقك للتأكد من أنه يلبي احتياجاتك. مع توسع تطبيقك، فكر في اعتماد تقنيات تحديد معدل الطلبات الموزعة للحفاظ على تحديد معدل طلبات متسق عبر جميع الخوادم. لا تنسَ أهمية التواصل الواضح مع مستهلكي واجهة برمجة التطبيقات عبر رؤوس حدود المعدل ورسائل الأخطاء المفيدة.